home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / hp48_2 / lib.for / comp.sys.handhelds_2341_000000.msg
Internet Message Format  |  1991-04-12  |  6KB
  1. Path: en.ecn.purdue.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!purdue!haven!uflorida!rex!wuarchive!usc!apple!rutgers!ub!acsu.buffalo.edu
  2. From: cloos@acsu.buffalo.edu (James H. Cloos)
  3. Newsgroups: comp.sys.handhelds
  4. Subject: Today the subject is libraries (LONG)
  5. Keywords: libraries, finally
  6. Message-ID: <46387@eerie.acsu.Buffalo.EDU>
  7. Date: 15 Nov 90 03:47:24 GMT
  8. Sender: news@acsu.Buffalo.EDU
  9. Followup-To: comp.sys.handhelds
  10. Distribution: comp
  11. Organization: State University of New York @ Buffalo
  12. Lines: 123
  13.  
  14. Yup, you guessed it; I spent the last few hours pouring over hex dumps
  15. of libraries, both created from directories by usrlib, and some from
  16. the bbs.  Anyway, this is what I found out:
  17.  
  18. (NB, each of these fields is individually reversed in memory; unlike
  19. the dir posting, I'll write these in readable format.)
  20.  
  21. A library looks like this:
  22.  
  23. #02b40        LIB header
  24. #nnnnn        size of the library, incl this field.
  25. #nn        the length of the lib's name, in chars
  26.  
  27. (If the lib is unnamed, this is #00 and the next two fields are missing)
  28.  
  29. asciiascii    the name of the library
  30. #nn        the length of the lib's name, again
  31.  
  32. (Now back to always there mode :)
  33.  
  34. #nnn        the LIB's id number
  35. #nnnnn        offset to hash table    \
  36. #nnnnn        offset to message arry    | offsets are from the start of
  37. #nnnnn        offset to link table    | the offset field 
  38. #nnnnn        ofset to config object    /
  39.  
  40. the data follows.
  41.  
  42. Named xlibs are stored in the format:
  43. #000 or #8    000=ok in alg expressions, 8= not ok in algebraics
  44. #nnn        lib's id number from above
  45. #nnn        the xlib's member number
  46. the actual object, starting w/ a std type field.
  47.  
  48. (You'll find that lib #002 (the usrlang commands) is stored this way also.)
  49.  
  50. Unnamed xlib's are stored w/o the #000nnnmmm or #8nnnmmm header, so
  51. you just start w/ the type field.
  52.  
  53. The config object is what is evaluated after each system halt, and is
  54. usually a program. To borrow from the usrlib doc file, make sure this
  55. DOES NOT LEAVE ANYTHING ON THE STACK OR DROP ANYTHING THAT WAS THERE.
  56. My assumption is that only a ram clear will fix the 48 if there is a
  57. lib installed that has a bad config obj, as the post-system-halt
  58. routines will probably crash each time you try one.
  59.  
  60. The link table is a hex string (a la a binary integer, but with a max
  61. wordsize of 2^5 - 6 nybbles) (proof of that is left as an exersise for
  62. the reader).  This hex string is 5 nybbles long per XLIB in the
  63. library, and each group of 5 nyb's forms an offset from the table to
  64. the beginning of the type field of each xlib.  These offsets are
  65. signed, so if this table is after the actual XLIB's, the offsets
  66. will be the complement (as per the NEG key on a binary integer--I'm
  67. too tired to figure out if this is 1's or 2's ;) of the actual
  68. distance from the field to the XLIB.  These are the only signed
  69. offsets I'm aware of so far, though maybe all offsets are, check your
  70. local saturn guru for details.  ;)
  71.  
  72. The message array is a simple array of strings.  (Which have the format: 
  73.  
  74. #029e8        type of ARRY
  75. #nnnnn        size of array, incl this field
  76. #02a2c        type of data in general, #2a2c is string type
  77. #nnnnn        number of dimentions
  78. #nnnnn        number of elements in 1st dimention
  79. ...
  80. #nnnnn          ''   ''    ''    '' nth    ''
  81. data
  82.  
  83. Where data is sum(i=1,no_of_dims,no_of_elem_in_this_dim) elements of
  84. the type specified.  In the case of strings, each of these looks like
  85. a 5 nybble size field (in nyb's incl itself) plus the ascii chars in
  86. the string.)
  87.  
  88. This leaves the hash table.  This is also a hex string.  At the end of
  89. this hex string are 5 nyb pointers for each named XLIB which point to
  90. that XLIB's name.  These names immediately precede the pointers.
  91. These offsets, though pointing backwards, are positive (or unsigned?),
  92. ie., #00020 would point 32 nybbles back from the start of itself.
  93.  
  94. The names these point to are in the familiar global name format, ie a
  95. 2 nybble size field (in char's, excluding itself) followed by that
  96. many bytes of ascii (each of course in reverse nybble order).  This is
  97. followed by a 3 nybble field of that XLIB's member number.  Before
  98. this is a 5 nyb field that is the length, in nybbles, of itself, & each
  99. of the XLIB names (inlc that name's length field and number field).
  100. Before all this, in each of the lib's I've looked at, is 85 nybbles of
  101. mostly 0's.  They seem to be 16 fields of 5 nybbles each (resonable
  102. thought) and there would seem to be on the order of 3 or so of these
  103. fields that contain any non zero data, this is usually only 2 nybbles.
  104. I presume they are some sort of offset, but to where (or from where
  105. for that matter) I've no idea.
  106.  
  107. The CONFIG, MESSAGE, LINK, HASH, and each individual XLIB can be, so
  108. far as I can tell, in any order, so long as each is itself contiguous ;^)
  109. I would presume, however, that there is some performance penalty if
  110. they are all mixed around, as minor as that might be (though if you
  111. use a XLIB in such a library in a type loop, these penalties could
  112. amount to a noticable delay).  (My compiler will use a standard order
  113. which is the easiest for me to put together. ;)
  114.  
  115. I better leave now, before I go over 900 words; I've already passed
  116. 100 lines.  Enjoy this info.  & like the post on dir's, if you don't
  117. understand it, ask & someone (maybe even me) will try to explain it
  118. better.  This *is* fun.  Trust me.  Really.  Would *I* lie to you?
  119. Seriously.  As much as this looks sarcastic, it isn't.  I promise.
  120.  
  121. BTW, the library: "04B20E10000066600000000000000000000577E" (in ASC
  122. format) is nothing but an unnamed lib, lib# = 666h = 1638d, w/o
  123. anything in it.  ASC\-> will work on the string, resulting in :
  124. `Library 1638: ` on the stack (w/o the `'s of course).  I'm not going
  125. to try installing it, as I don't feel like a mem lost just now.  Could
  126. someone out there who has a handy archive try this and report on it?
  127.  
  128. L8r, ffolks.
  129.  
  130. -JimC
  131. --
  132. James H. Cloos, Jr.        Phone:  +1 716 673-1250
  133. cloos@ACSU.Buffalo.EDU        Snail:  PersonalZipCode:  14048-0772, USA
  134. cloos@ub.UUCP            Quote:  <>
  135.  
  136. THIS INFORMATION COMES WITHOUT ANY FORM OF WARRENTY, NOT EVEN IMPLIED ONES.
  137.